The term “Web services” is understood to mean a standards-based, service oriented architecture (SOA) than can be used to engage in business relationships (e.g., buying and selling) in a partially or wholly automated fashion over a public network such as the Internet (“the Web”). Standards bodies and interoperability organizations that have contributed to the Web services effort include the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), the Internet Engineering Task Force (IETF) and the Web Services Interoperability Organization (WS-I).
FIG. 1 shows a Web services model 100 that includes a registry 101, a service provider 102 and a service consumer 103. A service consumer 103, or “service requester”, is generally understood to be an entity that seeks and (in cases where a suitable Web service is found) uses a particular Web service through a network 104. The registry 101 includes listings of various “available” services, and, may assist the service consumer 103 in searching for a suitable service provider based on the web servicing needs of the service consumer 103. A service provider 102 is the provider of one or more Web services that can be accessed over the network 104. Because of the vast expanse of the Internet and interest in automated business engagements, many registries, service consumers and service providers may be in operation at any instant of time.
Presently, the responsibilities of the most prevalent registry function 101 that is associated with the Web services effort are defined in various Universal Discovery, Description and Integration (UDDI) specifications provided by uddi.org. Besides providing listings of available services, a UDDI registry 101 may also make available to a service consumer 103 additional details that pertain to any particular Web service such as: 1) the location of the Web service (e.g., its URI specified by a specific network destination address or name); 2) the capabilities of the Web service (e.g., specific methods that are supported by the Web service and that may be called upon by the service consumer); and, 3) communication semantics needed for invoking the Web service through the network 104 (e.g., the structure of a messaging format and/or protocol needed to properly communicate with the Web service).
According to one widely adopted approach, such “additional details” are described in Web Services Directory Language (WSDL) text documents written in extensible Markup Language (XML). Here, for example, for each Web service that the registry 101 maintains a listing of, the registry 101 also maintains a WSDL document that describes the location, capabilities, and communication semantics of the Web service. Presently, a WSDL document for a particular Web service is expected to include an “abstract interface” description of the Web service (which includes the Web service's methods and the data passed between the Web service provider and Web service consumer) and a “concrete implementation” description of the Web service (which includes specific protocol and data format specifications for communicating with the Web service (referred to as a “binding”) and the location of the Web service (referred to as a “port”)).
According to another widely adopted approach, with respect to the actual communication that occurs between the service consumer 103 and the service provider 102, such communication is implemented through an exchange of Simple Object Access Protocol (SOAP) messages written in XML. A SOAP message includes an envelope 105 that further contains a header 106 (which may be optional) and a body 107.
For a particular Web service, the header 106 is typically used to pass “control” information associated with the consumer's Web service engagement with the Web service provider (e.g., information used for performing encryption/decryption and/or signature checking, information used to ensure proper ordering of SOAP messages, information that identifies the ultimate destination of the SOAP message, etc.). The body 107 is used to pass more “substantive” information associated with the service consumer's Web service experience (e.g., a specific method call from the service consumer to the service provider, or, a specific response generated by the service provider in response to a specific method call).
SOAP messages are typically deemed to be insensitive to the particular type of transport protocol used to transport them through the network 104. Thus, even though most SOAP messages are appended with an Hypertext Transport Protocol (HTTP) header, a header specific to a different type of transport protocol (e.g., HTTPS, SMTP, etc.) could be appended to the SOAP envelope 105 instead (e.g., if the service provider, service consumer and/or intermediary nodes were adapted to use the different type of protocol).
In basic cases where a service provider 102 receives a SOAP message sent by a service consumer 103, or, where a service consumer 103 receives a SOAP message sent by a service provider 102, the body of the SOAP message 107 essentially represents the purpose of the communication between the service provider 102 and service consumer 103. For instance, in the case of a SOAP message being sent by a service consumer 103 and received by a service provider 103, the purpose of the SOAP message may be that the service requester 103 desires that the service requester 102 perform a specific method. In this case, the body of the SOAP message 107 is apt to contain both a request to perform the specific method and any input parameters that are both needed by the method and determined by the service requester 103.
Presently, largely because of its versatility, the SOAP message is regarded as a primary unit of information transfer between a service provider 102 and a service consumer 103 in a Web services environment. Here, unlike many other kinds of messaging protocols, existing SOAP message specifications define a format that is relatively “abstract” in terms of its content and/or organizational requirements. Essentially, it is believed that a relatively abstract messaging format definition lends itself to having the versatility needed to support business relationship models of all different kinds (e.g., in terms of business relationship type and procedure), which, in turn, represents an overarching design goal of those designing the Web services infrastructure.
Nevertheless, for many types of business relationships, too much abstractness may correspond to the absence of specific structure deemed necessary to implement a truly workable automated business practice. For instance, a significant number of business models are expected to require confidentiality and/or assurances as to whom its SOAP message oriented communication is being entertained between. A significant number of business models are also expected to require guarantees that received SOAP messages will be processed in a specific order. Further still, a significant number of business models may desire to have the end-to-end communication path between service provider and service consumer be supported by different types of transport protocols (e.g., a first leg that is transported by HTTP and a second leg that is transported by SMTP).
FIG. 2 illustrates a prior art message transaction flow between a client and a server using a stateless HTTP connection. HTTP is a transactional protocol with the lifetime of a connection corresponding to a single request-reply sequence.
A client establishes a Transmission Control Protocol/Internet Protocol (TCP/IP) connection with a particular port/socket of a server at 201. The server opens the connection on its end and waits for a request message from the client at 203.
A request message is transmitted to the server from the client at 205. This message may be one that is requesting a document, header, for some action to be performed, etc. The client waits for a response message to be sent from the server after sending this request message.
Upon receiving the request at 207, the server processes the request (including committing the request) at 209 and transmits a response message to the client at 211. The client receives this response message at 213.
Once the request-reply sequence is completed, the socket is closed. For example, as shown both the client and server close the connection at 215 and 217 respectively. However, either the client or the server can close the stateless connection at any time for any reason.
FIG. 3 illustrates a prior art message transaction flow between a client and a server using a stateful HTTP connection. While HTTP is normally a transactional protocol with the lifetime of a connection corresponding to a single request-reply sequence, HTTP may be adapted to use state information through the use of cookies. A cookie is a small segment of text sent by a server to a client and then sent back to the server by the client (either with changes or unchanged) each time it accesses that server. The server may add information to an existing cookie prior sending or re-sending it to a client. Cookies are used for authenticating, tracking, and maintaining specific information about users, such as site preferences and the contents of electronic shopping carts.
A client establishes a stateful Transmission Control Protocol/Internet Protocol (TCP/IP) connection with a particular port/socket of a server at 301. A stateful connection in this scenario means that cookies will be used to save the state of the transaction. The server opens the connection on its end and waits for a request message from the client at 303.
A request message is transmitted to the server from the client at 305. This message may be a request for a document, header, some action to be performed, etc. The client waits for a response message to be sent from the server after sending this request message.
Upon receiving the request at 307, the server processes the request (including committing the request) and creates or edits a cookie associated with the client at 309, and transmits a response message (including cookie) to the client at 311. The client receives the response message at 313.
Once the request-reply sequence is completed, the socket is closed. For example, as shown both the client and server close the connection at 315 and 317 respectively. However, either the client or the server can close the stateful connection at any time. Like the stateless HTTP communication scheme, stateful HTTP communication ends after one request/response scenario, however, a state associated with the transaction is maintained in the form of a cookie and the next request/response cycle should include the cookie with all messages.
Transmitting, receiving, and processing a large number of messages (such as SOAP or HTTP messages) cause performance bottlenecks in the above prior art flows and architectures. For both the stateless and stateful communications, a message received by a server is committed and processed immediately. If there are a relatively large number of messages (for example, on the order of one-hundred or more) this processing may adversely tie up resources in the server. Additionally, if a group of messages is to be processed in a certain order, but the server does not receive these messages in that order, the server will not process the group correctly (as it processes the messages in the order that it receives them). This erroneous group processing will, at worst, require a rollback to the state prior to the reception of any member of the group. Additionally, there is no current standards acceptable way of packaging several messages together using Web services. An example of a bottleneck attributable to transmitting and receiving is the necessity of having to “log” onto a server every time a message is to be sent from a client to a server in a stateless communication.